The invention relates generally to computer systems, and more particularly to the caching of content such as downloaded network content.
For network client applications, such as web browsers, a limiting performance factor is often low bandwidth to the server. To mitigate this low-bandwidth problem, network client applications often cache content replicated from servers, so that as much information as possible is kept available on the client user""s hard drive. As data access times from the hard drive and RAM are typically orders of magnitude faster than download times, some or all of a server""s content may often be rapidly accessed from the cache with little or no downloading of data from the server. Using a cache results in a faster user experience, less network traffic and less server burden.
While content caching thus provides substantial performance improvements, a problem with caching is that the locally cached content is static, whereas the actual content (e.g., network content) may or may not have changed. To avoid this problem, HTTP (hypertext transfer protocol) provides for sending a conditional request, e.g., an xe2x80x9cIf-Modified-Sincexe2x80x9d (IMS) request, an xe2x80x9cIf-None-Matchxe2x80x9d request, or the like to the server, identifying the content by a timestamp or entity tag. When the server receives such a conditional request, it uses the timestamp and/or entity tag to test whether the content has changed, and, if the content has not changed, the server responds with a xe2x80x9cnot modifiedxe2x80x9d response, otherwise the server provides the modified content.
While this conditional request provides an overall increase in the available network bandwidth by reducing the amount of data that needs to be transmitted, not much in the way of savings is achieved at the server end. More particularly, the server often does almost as much work to determine if a content has been modified as it takes the server to simply retrieve and return the corresponding requested content. At the same time, many conditional requests may be made for content that is rarely, if ever, modified. This wastes server resources, increases client latency, and consumes available bandwidth.
One solution is to have the provider of the content include an xe2x80x9cExpiresxe2x80x9d header comprising a date/time stamp, a xe2x80x9cCache-Controlxe2x80x9d header specifying a max-age relative to the current time, or the like. When cached, the local system ordinarily does not send a conditional request before the particular time determined by the expiry mechanisms. However, this only works when the content provider provides an appropriate timestamp header, which frequently does not happen, sometimes because it is not appropriate for the content to have a distant expires time, e.g., the content is expected to change frequently, and sometimes because it is simply not used by the provider.
Regardless of whether the data is stale or fresh, when the server is not involved with a user request, the hit count maintained at the server for the site is not correctly counted, even though the user views the content. This is often significant, as the hit count influences advertising revenue. The IMS solution prevents this problem, however as described above, IMS requests have their own problems, e.g., they are often very slow, particularly with a slow connection and/or a busy server, since a request and response is needed for each request for content validation.
Briefly, the present invention provides the ability to selectively use content from the cache, with a synchronization of the content performed in the background. To accomplish this state of operation, two parameters may be specified, xe2x80x9cpost-checkxe2x80x9d and xe2x80x9cpre-check.xe2x80x9d These parameters enable a non-validate time period relative to the cached content""s timestamp to be specified in which the content is used from the cache, a background synchronization period in which content from the cache is used along with an automatic request for synchronization of the content, and a validate period in which a request for validation of content (or the content itself) will be made.
For example, a server may specify in an HTTP header or the like the xe2x80x9cpost-checkxe2x80x9d and xe2x80x9cpre-checkxe2x80x9d time-related values to establish three periods of time for synchronizing network content. In the non-validate and background synchronization periods, because cached content is used, (when available), an content will be quickly rendered for the user. In the background synchronization and validate periods, the hit count will be correct. If the server specifies the parameters, the server can control on a per-content basis in which state (time window) typical users primarily operate. For example, the server may set the parameter values such that users are mostly in the background synchronization time period for certain content, whereby the user has a fast experience via rapidly rendered content (including any advertising) from the cache, while via a background synchronization, the server receives the proper number of hits. Further, the server is still able to control how stale the cached data is allowed to become, so that even though the user is xe2x80x9cone behindxe2x80x9d in viewed content, the displayed content is known to be as relatively current as the server deems necessary.
Other advantages will become apparent from the following detailed description when taken in conjunction with the drawings, in which: